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REMARKS 

This response is a Preliminary Amendment that supplements the Request for 
Continued Examination (RCE) filed August 31, 2004. All objections and rejections are 
respectfully traversed. Reconsideration of the application, as amended, is respectfully 
requested. 

The specification has been amended to correct minor errors contained therein. 
Specifically, at page 9, line 1, the phrase "grants the tokens to the first process" has been 
changed to "grants the tokens to the second process." Also, the word "it' was removed 
from page 15, line 6 and the phrase '''whose grant message" has been changed to '''that 
grant message" at page 17, line 12. No new matter is being introduced. 

Claims 1-40 are pending. Applicant has added new claims 38-40 comprising 
similar subject matter previously presented in claims 1-37. Accordingly, no new matter 
is being introduced in the newly added claims. 

Claims 1-37 stand rejected under 35 U.S.C. §103 as being obvious over U.S. Pat- 
ent No. 5,742,812 issued to Baylor et al. (hereafter "Baylor") in view of U.S. Patent No. 
5,634,122 issued to Loucks et al. (hereafter "Loucks"). 

Applicant respectfully traverses these rejections for the same reasons presented in 
the Applicant's After-Final Amendment dated April 2, 2004. For convenience, these ar- 
guments are again presented below. 

Claim 1 recites in relevant part: 

"A computerized data file system, comprising:" 
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"a first process . . 

"a second process that generates a first message requesting that said sec- 
ond process be granted by said first process a plurality of tokens required for 
said second process to modify at least one characteristic of said file". 

In other words, claim 1 recites that a single message conveys a request, not for one, but 

for a plurality of tokens. 

Paragraph 4 of the final Office action, dated February 6, 2004, relies on the 
Loucks reference as purportedly teaching a single message requesting a pluraUty of to- 
kens that are required to modify a desired file. Applicant submits that, with all due re- 
spect, a fair and proper reading of Loucks does not support such a conclusion. Instead, 
Loucks, like the art described in the Backgroimd section of this application, can only re- 
quest one token per message. 

The final Office action cites to the Abstract and to Col. 3, lines 45-52 of Loucks 
as purportedly teaching a single message that requests a plurality of tokens. In the Ab- 
stract, Loucks explicitly states that tokens are only requested one at a time. Abstract, 
lines 5-7 ("Each requested operation checks for the proper token . If the token is not held 
by the process, it is requested.") The Abstract also notes that Loucks token manager can 
request authorization tokens from a local token manager, but Loucks provides absolutely 
no teaching or suggestion that multiple tokens can be requested by the token manager in a 
single message. Instead, given the explicit language in the Abstract at lines 5-7 quoted 
above, the only proper teaching of Loucks is that tokens must be requested one at a time. 

The other section of Loucks that was cited in the final Office Action, Col. 3, lines 
45-52, states as follows: 
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means for requesting authorization for a computer implemented process to per- 
form an operation on shared data; means for managing requests generated by the 
means for requesting; and means for granting authorization tokens allowing an 
operation to be performed on the shared data, the means for granting being re- 
sponsive to the means for managing. 

Applicant agrees that this excerpt states that Loucks' token manager grants multiple to- 
kens. However, this excerpt is completely silent as to how the computer implemented 
process looking for authorization requests one or more tokens, and thus provides no 
teaching or suggestion for a process that generates a single message requesting a plurality 
of tokens in order to modify a file. It is improper for the final Office action to read into 
this excerpt fi-om Loucks particular teachings that are wholly absent. Again, this excerpt 
provides no teaching or suggestion for the generation of single message that requests a 
plurality of tokens, as recited in claim 1. 

Consideration of Loucks in its entirety, moreover, clearly demonstrates that to- 
kens are requested one at a time. In particular, the following excerpts from Loucks all 
show that tokens are requested one at a time: 

(1) Col. 6, lines 28-29 ("When the token requester, mtkr 418, of an MDFS 
client requests a token from the token manager . . ."); 

(2) Col. 6, lines 3 1-32 ("it may request a new token from the local token 
manager . . ."); 

(3) Col. 7, lines 4-5 ("If the requested token does not conflict . . ."); 

(4) Col. 9, lines 36-37 Hf the Stash token is requested . . ."); 

(5) Fig. 8A, block 804 ("Request token fi-om Itkm"); 

(6) Fig. SB, block 816 ("Wait for token request"); 
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(7) Fig. 9A, block 903 ("Get Open_Write token for fileset y"); 

(8) Fig. 9B, block 938 ("Identify Requester and requested token ") 
All of the above excerpts clearly demonstrate that a request issued by one of 

Loucks' processes is only for a single token. There is no teaching or suggestion by 
Loucks for a single message that can somehow request a plurality of tokens. Loucks does 
state that, over time, multiple tokens can be requested (Col. 7, lines 55-57), but the only 
teaching provided by Loucks is that multiple messages or requests must be issued in or- 
der to obtain those multiple tokens. Because Loucks fails to teach or suggest a single 
message for requesting a plurality of tokens, the rejection of claim 1 should be with- 
dravra. The rejection of claims 2-5, which depend from claim 1, should also be with- 
drawn. Furthermore, claims 11-18, 20-31 and 35-36 all recite a single message or request 
for a grant of a plurality of tokens. Accordingly, these claims are also allowable over the 
art of record for the same reasons set forth above. 

Claims 6-10, 19 and 32-34 all recite the issuance of a single message that grants a 
plurality of tokens. Loucks also fails to provide any teaching or suggestion for the issu- 
ance of a single message granting a plurality of tokens. Instead, Loucks repeatedly states 
that only a single token is ever issued at any one time. For example, block 826 of Fig. 83 
recites the step "Grant token", i.e., one token. Block 916 of Fig. 9A and block 956 of 
Fig. 9B both recite the step "Grant token" , i.e., one token. Thus, the only teaching pro- 
vided by Loucks is to grant a single token at any one time. There is no teaching or sug- 
gestion by Loucks for somehow granting multiple tokens in a single message. 
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Applicant submits that the application is in condition for allowance and early fa- 
vorable action is requested. 

It is believed that no extensions of time or fees are required, beyond those that 
may otherwise be provided for in documents accompanying this paper. However, in 
the event that additional extensions of time are necessary to allow consideration of this 
paper, such extensions are hereby petitioned under 37 C.F.R. §1. 136(a), and any fees 
required (including fees for net addition of claims) are hereby authorized to be charged 
to Hewlett-Packard Development Company's deposit account no. 08-2025. 



Send all correspondence to: 

IP Administration Legal Department, 
M/S35 

Hewlett-Packard Co. 

P.O. Box 272400 

Fort Collins, CO 80527-2400 



Respectfully submitted, 




Stephen E. Kabakoff 
Reg. No. 51,276 
(617) 951-2500 
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